This invention relates generally to systems for providing graphics environments for application programs, and more particularly to common window management interfaces for systems capable of running multiple application programs written for various environments.
In modern data processing, protocols allow application programs to communicate with system components such as I/O devices or servers. These protocols include application programming interfaces, interprocess communication protocols, and remote procedure calls. With the rapid growth of computers and application programs, there has been a parallel growth in the number of software and hardware protocols. The existence of multiple protocols throughout the data processing industry has been a source of inconvenience because application programs written for one protocol must be modified, rewritten, or even redesigned, for a different protocol.
The problem of multiple protocols is particularly acute in the graphics area where there are a number of standards in use. Certain graphics systems use a software package called a display server to implement a graphics protocol. In such systems, application programs requesting graphics services, called clients, send their graphics requests to the display server.
The graphic services can include window management. Windows are areas on a video screen that allow a user to view data processing output. Windows also give application programs an organized way of managing the use of space on the screen, and allow the display server to present information for multiple application programs in an organized way. If clients want windows, another software package called a "window manager" is generally used to control certain window management functions.
By using a window manager, individual clients need not be concerned with window management functions, such as the positioning and sizing of windows. An example of a graphics system having a window manager common to a number of clients is one defined by the X Window System protocol, a standard developed at the Massachusetts Institute of Technology. FIG. 1 shows an X Window system, where client 110, 120, and 130 send graphics request to X display server 140, thereby communicating with graphics hardware 150. Client 130 is a window manager that can provide window management functions to both clients 110 and 120.
Basic principles and architecture of the X Window System may be found in "Introduction to the X Window System" by Oliver Jones, Prentice-Hall 1989. The protocol for communicating with an X Window display server is described in "X Window System Protocol MIT X Consortium Standard X Version 11," Release 4, by Robert W. Scheifler, MIT Laboratory for Computer Science. Conventions for communicating with the window manager, and with other clients, are described in "Inter-Client Communication Conventions Manual, Version 1.0, MIT X Consortium Standard," by David S.H. Rosenthal, Sun Microsystems, Inc.
X Window Systems are not the only graphics systems in use throughout the industry. Therefore, it may be necessary to execute clients written for an X Window System together with clients written for some other type of windowing system on a common set of graphics hardware. For purposes of the discussion that follows, the other type of windowing system will be referred to generically as a "host system."
One proposal for providing window management functions for a data processing system running both clients using the X Window System protocol ("X clients") and clients using the host system protocol ("host clients") is shown in FIG. 2. FIG. 2 shows a unified window system 200 serving both X display server clients 210 and 220 and host server clients 230, 240 and 250. A common window manager 260 is provided to present a uniform window interface to the user. An X server front end 270 implementing the X display server shares common support functions 290 (conventions, code, data structures, hardware access structures, etc.) with a host server front end 280 implementing the host server, thereby allowing hardware resources to be harmoniously allocated.
System 200, however, has several disadvantages. First it requires writing both an X display server front end and a host server front end. Second, it is not easy to build system 200 from existing host systems because of the many modifications required.
FIG. 3 is an example of an existing host system 300 which supports host system clients 310, 320, and 330. System 300 also includes a host server 340, including an internal window manager, to provide graphics functions to host system clients 310, 320 and 330.
Converting system 300 of FIG. 3 into system 200 shown in FIG. 2 presents both legal and technological problems. For example, the person attempting to implement the X display server in system 300 might not possess the legal right to modify the support technology used in the host server 340. Also, the support technology of the host server may be poorly documented or structured in such a way as to make it difficult or impossible to adapt to support another server. Therefore, it is desirable not to have to modify existing host systems.
FIG. 4 shows another proposal to solve the X-server/host system integration problem. In system 400 shown in FIG. 4, host clients 410, 420, and 430 of the host system are connected to a host server 440 that includes window management functions. Another host client 450 is an X display server that operates by translating X protocol to host protocol. X clients 460 and 470, which are written with the X protocol, are coupled to client 450 and thus can run using the graphics hardware 490 attached to host server 340 as host clients 410, 420 and 430 do.
In an X Window System, the common window manager is the window manager client. This window manager client is connected to the X display server, as are X clients. Clients send requests to the X display server to effect graphics operations. Certain requests sent from X clients to the X display server are redirected by the X display server to the window manager client. The window manager client then processes the request, and may then send a request to the X display server. Other certain requests sent from X client to the X display server are processed by the X display server and notification is sent to the window manager client.
When using the different types of clients in a single system as described above, it is desirable to present a user with a uniform user interface. One way to achieve this would be to tailor the window manager 480 of the X type system to have the window interface of the host system. One disadvantage of system 400 is that the process responsible for starting window manager 480 would need to have knowledge of the type of host system in order to allow it to select a manager having the window interface of the host system. If the host system changes, a new window manager 480 is required. This is a problem because the process starting the window manager may exist on a network node separate from the host system, where it may be difficult to obtain knowledge of the type of host system. The separation of window manager 480 from X server 450 can make it difficult to track changes to the host system.